NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/1856

Internet Message Format | 1996-08-06 | 1.7 KB

Path: news.th-darmstadt.de!news!enno
From: [e-mail] (Enno Sandner)
Newsgroups: comp.lang.c++
Subject: Re: Destructors in functions
Date: 13 Jan 1996 13:37:57 GMT
Organization: Fachbereich Informatik, TH Darmstadt
Distribution: world
Message-ID: <[e-mail]>
References: <4d7r65$[e-mail]>
NNTP-Posting-Host: kitz.intellektik.informatik.th-darmstadt.de
In-reply-to: [e-mail]'s message of 13 Jan 1996 03:40:37 -0500

In article <4d7r65$[e-mail]> [e-mail] (Weatby) writes:

   If you pass an object to a function, the language makes a bitwise copy of
   it, local to the function.  (Assuming no copy constructor is defined.)
   Then, on the way out, the function calls the user-defined constructor.

   This will cause problems if the object has any pointers in it (if they are
   released by the destructor, as they 'should' be).

   The question is, why call a destructor on an object for which no
   constructor was called?  The compiler has probably put the local copy on
   its stack, and could pop it off on the way out.

   Calling a destructor, automatically, for which no constructor was called
   seems to be a non-useful feature.  Does anyone know why this was included
   in the language definition?

The default copy-ctor provided by the compiler does memberwise _not_ bitwise
copy of the data-members. That could be the same, if e.g. all data-members
are builtin types, but usually there is a difference.
So it's reasonable to call the dtor in general when the copied instance goes
out of scope. Anyway I don't think the standard _forbids_ optimization for
trivial dtors.

        Enno